The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
BGP graceful restart, specified for example in “Graceful Restart Mechanism for BGP,” by Sangli, S., E. Chen, R. Fernando, J. Scudder, and Y. Rekhter, January 2007, RFC 4724 of the Internet Engineering Task Force (IETF), requires a complete re-advertisement of routing information across a session restart, even though partial or even complete routing information may have been preserved. For example, even if a communication session with a receiving speaker is restarted, the receiving speaker can still temporarily maintain previously received routes, and thus re-advertising of the same routing information to the receiving speaker may be unnecessary.
Unnecessary re-advertising of the routing information after a session restart can delay routing re-convergence because re-advertising can be time consuming.
This disclosure assumes a technical understanding of at least the following, as well as all foundation technologies that are referenced in: [RFC2918] Chen, E., “Route Refresh Capability for BGP-4,” RFC 2918, September 2000; [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., “A Border Gateway Protocol 4 (BGP-4),” RFC 4271, January 2006; [RFC4724] Sangli, S., E. Chen, R. Fernando, J. Scudder, and Y. Rekhter, “Graceful Restart Mechanism for BGP,” January 2007; [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, “Multiprotocol Extensions for BGP-4,” RFC 4760, January 2007; [RFC5492] Scudder, J. and R. Chandra, “Capabilities Advertisement with BGP-4,” RFC 5492, February 2009; US Patent Publication No. 2006/0171404; US Patent Publication No. 2008/0089231; US Patent Publication No. 2008/0089348.